home *** CD-ROM | disk | FTP | other *** search
Text File | 1995-12-03 | 3.3 KB | 88 lines | [TEXT/CWIE] |
- PICSee Dust Notes:
- Hiep Dam
- 12/3/95
-
- For PICSee Dust version 1.01
- Source code (whatever I wrote) is free.
-
-
- The Viewer
- ===========
-
- The Viewer supports the internal PICS information resource, 'INFO'. The only
- parameter that the Viewer uses, however, is the speed parameter. All others
- (depth, version, etc) are ignored.
-
- By default, if the speed of the PICS file is changed, or if it never had
- an 'INFO' resource to begin with, the Viewer will save the the speed to
- the 'INFO' resource (or create one if none existed).
-
- You can tell the Viewer not to save the speed by keeping the <shift> key
- down while closing the PICS Viewer window.
-
- Also, the Viewer retrieves from the preferences whether to change the
- file's creator type. If the file is modified in the above cases and if
- the preferences are set to change the creator types, the Viewer will
- update the PICS file info so that it's creator type matches that of
- PICSilicious.
-
-
- The Compositor
- ==============
- <updated later>
-
-
- The PICS Splitter
- =================
- The splitter will save the PICS file as PICT files, with either the
- PhotoShop or Color-It creator type or the user-defined type.
-
-
- The PICS Merger
- ================
- The merged PICS file will have the PICSilicious creator type (since
- the original PICT file creator types - supposedly PhotoShop or
- Color-It - do not really support the PICS file format).
-
-
-
- Stuff I've have to tweak out that I'm not comfortable with
- ----------------------------------------------------------
- 1) Update events: I've had to write an AppEmergencyUpdate() routine to handle
- update events which aren't handled.
-
- Example: put up one dialog, dismiss it and immediately put up another dialog.
- Notice the ugly white areas resulting from the old dismmissed dialog. These
- areas won't get update events until after the second dialog is dismissed. Note
- that this could happen even if you don't have a second dialog, but instead
- perform some lengthy operation. The update event doesn't get called until
- the next pass at WaitNextEvent - which doesn't happen until your lengthy
- operation is done.
-
- AppEmergencyUpdate() goes through all windows in the app and gives them
- an update message. Nice fix, but windows in other processes won't get
- updated. No fix for this, I think.
-
- Read Apple TB37: Pending Update Perils (TB == newer Tech Notes) for
- the lowdown...
-
-
- 2) AppendDITL: Using this causes an update event for the dialog (instead of
- it just calling DrawDialog). If you have other items which are *erased*
- and redrawn in response to update events, and they are not effected by
- the change in DITLs, you'll get noticeable flicker. These items are
- in effect getting spurious update messages - they don't need updating,
- only the added DITLs do.
-
- I've added a static global in one case, in which I set it if I've used
- AppendDITL (and thus causing the update event). When my update routine
- is called, it checks this global flag. If the flag isn't set, I know
- that AppendDITL wasn't called and this is a bona-fide real update event.
- Erase and redraw.
-
-
- 3) The select multiple files dialog in the Merge... menu command isn't
- quite working as I would like. Also, it's not PowerPC-compatible
- (it compiles fine with my modifications, but will crash at runtime).
- However, since I didn't write it I'm not complaining. I will try to
- fix the problems in the next release.